<?php
/**
 * <https://y.st./>
 * Copyright © 2019 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'Access control',
	'<{subtitle}>' => 'Written in <span title="Databases 2">CS 3306</span> by <a href="https://y.st./">Alexand(er|ra) Yst</a>, finalised and <a href="https://y.st./en/coursework/CS3306/Access_control.xhtml">archived</a> on 2019-05-08',
	'<{copyright year}>' => '2019',
	'takedown' => '2017-11-01',
	'<{body}>' => <<<END
<div class="APA_title_page">
	<p>
		Access control<br/>
		Alexand(er|ra) Yst<br/>
		<span title="Operating Systems 2">CS 3307</span>
	</p>
</div>
<h2>$a[RBAC]</h2>
<p>
	$a[RBAC] is a method of designating a user&apos;s permissions based on their role within an organisation {{{CITE}}}.
	For example, an end user would be given a role that doesn&apos;t allow them to perform administrative tasks.
	This serves a couple of purposes.
	First, you don&apos;t need to trust the end user&apos;s intent and give them access to the whole system.
	You can trust them with only the parts they can&apos;t break and can&apos;t get restricted information from.
	Second, you don&apos;t need to worry about threats not intended by the end user, but acting through the end user or the end user&apos;s account.
	For example, one of the biggest reasons Windows viruses are so prevalent is because the main user is given full permissions, which they really don&apos;t need.
	When they accidentally install a virus, that virus is able to act on the entire system because the user that accidentally installed and ran the virus had full access to the system.
	Because the virus runs in the user&apos;s account, it has the user&apos;s full permissions.
	By similar logic, even if you trust the intent of your users, locking them out of the parts of the database that they shouldn&apos;t try to access prevents unintended modification from things such as malware that acts through the user&apos;s account.
</p>
<p>
	Roles are assigned based on the role the user plays in the organisation.
	Administrators have higher permissions due to their elevated role when using $a[RBAC].
	This means they can administrate the system, but they can also damage the system.
	The administrative role should be granted to as few users as possible: only those that actually need that access to do their job.
</p>
<h2>$a[LBAC]</h2>
<p>
	It can aid understanding to compare to an alternative.
	One alternative to $a[RBAC] is $a[LBAC].
	$a[LBAC] functions using a series of security labels and security policies.
	Each table can have its own security policy, but no more than one security policy can be used for any given table.
	The policy identifies labels and uses them to determine which pieces of data within the table the user is allowed to access.
	These labels can be used to identify people from a given department or working on a particular project, for example, allowing only those that need access to the data to have it (IBM, n.d.).
	Data that is access-controlled in such a way is referred to as &quot;protected data&quot;.
</p>
<h2>Conclusion</h2>
<p>
	It&apos;s hard to say for sure without a source that directly compares the two (I looked, but couldn&apos;t find one), but it seems like $a[LBAC] offers more control, but at the cost of extra storage space use and likely extra processing.
	You can use as many security labels as you want to restrict access to the data in the way that you need, but this doesn&apos;t come gratis.
	$a[RBAC] seems sufficient in most cases, but it offers less control.
	It looks like users are assigned one role across the entire database, saving space and processing, but you don&apos;t get to tack on extra qualifiers such as what projects a given user is working on at the time; at least not without adding an extra role for each combination of actual roles and current projects you want to allow.
</p>
<div class="APA_references">
	<h2>References:</h2>
	<p>
		IBM. (n.d.). <a href="https://www.ibm.com/support/knowledgecenter/SSEPGG_9.8.0/com.ibm.db2.luw.admin.sec.doc/doc/c0021114.html?view=embed">Label-based access control (LBAC) overview</a>. Retrieved from <code>https://www.ibm.com/support/knowledgecenter/SSEPGG_9.8.0/com.ibm.db2.luw.admin.sec.doc/doc/c0021114.html?view=embed</code>
	</p>
	<p>
		Zhang, E. (2019, April 26). <a href="https://digitalguardian.com/blog/what-role-based-access-control-rbac-examples-benefits-and-more">What is Role-Based Access Control (RBAC)? Examples, Benefits, and More</a>. Retrieved from <code>https://digitalguardian.com/blog/what-role-based-access-control-rbac-examples-benefits-and-more</code>
	</p>
</div>
END
);
